Distributed transactions are often performed on distributed computing systems. A distributed transaction is a set of operations that update shared objects. Distributed transactions preferably should satisfy the properties of Atomicity, Consistency, Isolation and Durability, known commonly as the ACID properties. According to the Atomicity property, either the transaction successfully executes to completion, and the effects of all operations are recorded, or the transaction fails. The Consistency property ensures that the transaction does not violate integrity constraints of the shared objects. The Isolation property ensures that intermediate effects of the transaction are not detectable to concurrent transactions. Finally, the Durability property ensures that changes to shared objects due to the transaction are permanent.
To ensure the Atomicity property, all participants of the distributed transaction must coordinate their actions so that they either unanimously abort or unanimously commit to the transaction. A two-phase commit protocol is commonly used to ensure Atomicity. Under the two-phase commit protocol, the distributed system implements the commit operation in two phases. In the first phase, a node in the distributed computing system managing the transaction asks all participants (nodes in the distributed computing system participating in the transaction) whether they are able to commit to the transaction. During the second phase, a coordinator node determines whether the transaction should be completed. If during the prepare phase all participant nodes committed to the transaction, the coordinator node successfully completes the transaction and sends commit messages to each of the participants. If during the prepare phase one or more participant nodes failed to commit to the transaction, the coordinator node does not complete the transaction and sends a roll back message to each of the participants.
The traditional two-phase commit protocol supports updating multiple resources. However, large scale systems, such as NoSQL data stores, do not support two-phase commit transactions due to other design considerations. During the first phase of a two-phase commit transaction, a lock is placed on the resource to be updated in order to ensure the Atomicity property, which can delay other system components that rely on a locked resource. Moreover, scalability of systems that use two-phase commit protocols is restricted due to the time it can take between the two phases and the requirement that participating resources recognize the two-phase commit protocol.
Other conventional distributed systems have implemented a one-phase commit protocol. A one-phase commit protocol does not use a prepare phase prior to committing resources to a transaction, and so may not satisfy the atomicity feature of the ACID properties if a resource is to modify more than one entity (e.g., more than one document or data item). The two-phase commit protocol provides strong consistency while the one-phase commit protocol provides high availability of resources.